Columbia Kermit/kermit.zip/newsgroups/misc.20021006-20030409/[e-mail]_Sun Dec 1 12:18:25 EST 2002.msg

Text File | 2020-01-01 | 13KB | 224 lines

Article: 13896 of comp.protocols.kermit.misc
Path: newsmaster.cc.columbia.edu!watsun.cc.columbia.edu!jaltman
From: [e-mail] (Jeffrey Altman)
Newsgroups: comp.protocols.kermit.misc
Subject: A Letter to the Kermit Community
Date: 1 Dec 2002 10:11:53 GMT
Organization: Columbia University
Lines: 208
Message-ID: <ascn99$pl1$[e-mail]>
NNTP-Posting-Host: watsun.cc.columbia.edu
X-Trace: newsmaster.cc.columbia.edu 1038737513 26273 128.59.39.2 (1 Dec 2002 10:11:53 GMT)
X-Complaints-To: [e-mail]
NNTP-Posting-Date: 1 Dec 2002 10:11:53 GMT
Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:13896

1 December 2002:

Today marks the end of a significant period in my life.  For the last
eight years I have been privileged to work on and support Kermit as my
career.  I began working for Columbia University after nearly seven
years as a Kermit user and eventually as primary developer of OS/2
C-Kermit which became the basis for Kermit 95 on Windows 95/98/ME
and Windows NT4/2000/XP.

During this time the Kermit project shipped 23 releases.  The initial
version of K95 was shipped on Oct 5, 1995 just seven months after I
joined Columbia University.  K95 was not only a port of OS/2 C-Kermit
to Windows but an attempt to make C-Kermit easy to understand for
beginners by adding a Graphic Front End and to do so in a manner that
would be inherently cross platform.  Back then our dreams were to
build a front end that could be supported on OS/2 and 32-bit Windows
with the ability to easily port it to MacOS and X-Windows.  At the
time our development platform had to be selected Java was not even
announced to the world.  (That occurred in early August 1995.)  We
selected Zinc as our cross platfrom development environment.
Unfortunately, cross platform development environments that wrap
existing OS components tend to be lowest common denominator feature
sets and result in apps that are not entirely what the end user
expects.  (Java discovered this with the original AWT library and
eventually constructed the Swing library to avoid the OS dependencies.)

For Kermit, the reliance on Zinc allowed us to easily support both
OS/2 and Windows but resulted in significant compromises in features
as the years went on.  The Zinc library was not only LCD but also
suffered from two significant problems:

 . it is a memory and gui resource hog

 . the authors never checked memory buffer overwrites

These two issues resulted in significant problems in pre-1.1.21
releases of Kermit 95.  First, as the number of configurable items
in the Settings Notebook increased the required gui resource allocation
increased to more than 30% of the total gui resources available on
Windows 95/98/ME.  This would result in unpredictable crashes.

The memory overwrite bugs were primarily caused by a failure to
allocate enough memory for path names.  The Zinc library was
originally developed to support DOS, 16-bit Windows, and OS/2.  The
8.3 filename restrictions coupled with the limited drive space
available on those systems resulted in short pathnames.  It seems they
never anticipated that anyone would want a pathname greater than 64
characters.  Now with todays GUIs coupled with removal of the 8.3
restrictions it is common for the filename to be 64 characters not
even considering the rest of the pathname.  The memory overwrites
produced data corruption in the Zinc databases that stored the
Connection Configurations.  The problems became more obvious as users
switched to Windows 2000 and began to install K95 in directories with
long pathnames or across network shares access via UNC names.

For 1.1.21 and later these issues were addressed by a combination of
extensive debugging of the Zinc libraries coupled with limiting the
number of GUI resources allocated at once.  It is due to the latter
that the Settings Notebook was broken up into separate (although
annoying) settings pages.

I'm not going to say that the choice of Zinc was a disaster, but in
hindsight it would have been better if the decision to use Zinc could
have been put off until Java for desktop development began to
stablize.  However, waiting until mid-1997 was not an option and now
that Zinc has been deployed Kermit 95 has become dependent on its
database format.  Any attempt to migrate to something else would
require either abandoning the existing user data or re-implementing
the Zinc database format in the new language.  Neither are desireable,
nor did we ever have the resources.  The use of Zinc did succeed in
its initial goals:

  construct a GUI front end for C-Kermit that would reduce the
  need for end users to understand the C-Kermit command language
  in order to configure and establish connections to hosts over
  a wide range of connection types; and do so on multiple operating
  systems on multiple architectures in a manner that allowed for
  database portability.

The initial versions of K95 were shipped on OS/2 (X86) plus Windows
95/NT4 (X86,MIPS,Alpha,PPC).  We even had a PowerPC version for OS/2
but it was never publicly released since the operating system itself
was never released.  It was possible to use a single Dialer database
on multiple operating systems in multi-boot scenarios.  At one point I
had a database shared by OS/2, Windows 95, NT4, and Windows 95 (Hebrew
edition.)

Porting OS/2 C-Kermit to Windows was a challenge in itself.  C-Kermit
is a single threaded application.  OS/2 C-Kermit is multi-threaded
(separate threads for command processor, keyboard/mouse input, screen
display, and device/network I/O processing) but it can count on all
thread independent signals being delivered to the first thread in the
process.  In Windows, thread independent signals are delivered to the
process in their own thread.  To this day I am still not satified with
the cross platform model I developed to handle events such as SIGINT.
The existing implementation works well enough for most purposes and
there have always been an endless number of new features to add to K95
such that I have never had the time to re-visit the design of this
fundamental building block.

Looking back over the last eight years it is somewhat incredible to
think about what was acheived.  In 1995, the source code for K95 was
less than 80,000 lines in total.  The executable for the Windows X86
was 786k.  For the 2.1 release the base source code over 500,000 lines
of code not including support for SRP, Kerberos, SSL/TLS, and SSH; the
k95g executable is 3566.5K.  The security protocol support adds another 1.2
million lines of source code plus almost 3MB in supporting DLLs.

Then there is all of the documentation that was written: 88,000 lines
(the original release had 5235 lines of documentation.)  [This does
not include the "Using C-Kermit" book which Frank and Christine were
able to update only once during this time frame.  To accomodate all of
the new documentation which has been written, an updated "Using
C-Kermit" current with version 8.0 would need to be 1800 pages in
length.]

I tried to look back and summarize all of the features that were added
to Kermit in the last eight years and I became overwhelmed.  There
were 35 plus terminals that were emulated; streaming Kermit protocol;
the Internet Kermit Service; all of the IETF work (TELNET AUTH SRP,
TELNET AUTH KRB5, TELNET START-TLS, TELNET FORWARD-X, PKIX, TLS,
KERBEROS 5, SSH 2, FTP AUTH TLS; TN3270 extensions; DNS SRV); UTF8
terminal support; URL hotspots; mouse event programming; Windows
Telephony; DECNET; TELNET; RLOGIN; KLOGIN; Remote COM-PORT-CONTROL;
HTTP; FTP; all of the security implementations; Bidirectional Printer
Management; the GUI release; export permission; and thousands of other
things that I just can't summarize because (to be honest) I can't
remember.  I tried to use the Internet Wayback Machine

  http://web.archive.org/web/*/http://www.columbia.edu/kermit/k95.html

but its almost as if everything on the current k95.html page is new.

One of the greatest aspects of my work on Kermit has been that the
impact of my work has not been limited only to the Kermit product and
its users.  Through Kermit I have participated in the Internet
Engineering Task Force on numerous working groups and have either
authored or edited over two dozen Internet-Drafts and RFCs.  In
addition, I have been an active contributor to various OpenSource
projects: OpenSSL; MIT Kerberos; Tom Wu's Secure Remote Password
distribution; Peter Runestig's Secure Telnet and FTP clients and
servers; Denis Sbragion's Sredird Telnet Com-Port-Control daemon; plus
many others.  I participated as an unofficial observer in the Commerce
Department BIS advisory council meetings on export control.  Plus I was
able to work with purely commercial companies to help them ensure that
their products were compliant with protocols implemented within Kermit.

With all of this there is always more that I wish I could have
accomplished.  We never did implement TN3270/TN5250 within Kermit.
Nor did we ever port the terminal emulator to MacOS or X-Windows.  The
BeOS port never truly worked and we don't support PalmOS or Windows
CE/PocketPC devices.  The Internet Kermit Service never received wide
enough support from OS vendors such as IBM, Sun, HP, Compaq, and
RedHat.  Support for security features on VMS is still not complete.
We never got to develop a drag/drop file transfer interface for
Kermit, Zmodem, and FTP.  But overall I believe that Kermit 95 is a
very good product that in many ways probably does too much.  :-)

Unfortunately, my time to work on Kermit as a Columbia University
staff member has come to an end and it is time for me to move on to
other endeavors even if I am not quite sure what they will be.

I still consider myself a member of the Kermit Project even if I am
not paid to be.  Kermit has been a part of my life for fifteen years.
It was a lab for me when I was in college and then grad school.  When
I got my first job as a developer after receiving my Masters I
continued to work on C-Kermit eventually taking the reins of the OS/2
port from Kai Uwe Rommel.  I left that job for Columbia because the 20
hours a week I was spending on Kermit was a lot more enjoyable than
the work I did for my employer.  I can't imagine how it would be possible
for me to simply give it up now but my work on Kermit has caused me to
grow far beyond what is possible within Kermit.  Therefore, Kermit is
going to have to become a smaller piece of my life.

My participation in open source projects such as MIT Kerberos and
OpenSSL will continue.  My participation in the IETF will continue.
Over the last year and a half I have become very interested in Peer to
Peer overlay networks and purely distributed authentication systems.
I have been active in the Project JXTA community <http://www.jxta.org>
and currently sit on its Board.  I have been actively pursuing the
creation of an IETF P2P Working Group to standardize a suite of P2P
protocols; and an IRTF P2P Research Group to study the effects of P2P
overlay networks on an Internet containing 10^14 nodes (today's
Internet has less than 10^9 nodes.)  It is my hope that my next
employeer will provide me the opportunity to continue this work.

In the meantime, I will be available on a contract basis through
Internet Access Methods <http://www.iamethods.com> /
<http://www.iamx.com> for development or consulting work on Kermit;
Peer to Peer systems; or various Security efforts.  I can be
reached either at jaltman AT columbia.edu or jaltman AT iamx.com.

Last but not least I want to say thank you to Frank da Cruz, Max
Evarts, Christine Gianone, everyone I've worked with at Columbia
University; and all of the wonderful users that have supported Kermit
over the years most notably: Peter Runestig, Mark Zinzow, Kent Martin,
Arthur Marsh, Perry Wolfe, Robert Strickler, Greg Belenger, Clarence
Dold, Thomas Dickey, Jim Schneider, Vincent Fatica, Gene Alexander,
and everyone else whose name I can't pull off the top of my head.
Without you Kermit would not be any fun at all.

Jeffrey Altman
Volunteer Kermit Developer

 Jeffrey Altman * Volunteer Developer      Kermit 95 2.1 GUI available now!!!
 The Kermit Project @ Columbia University  SSH, Secure Telnet, Secure FTP, HTTP
 http://www.kermit-project.org/            Secured with MIT Kerberos, SRP, and
 [e-mail]               OpenSSL.